





BASIC Stamp 
programming course 


Part 8 (final): the photophobic robot 


By Dennis Clark 


Phase 3: the photophobic robot 
and subsumptive programming 


It would be interesting if the robot had some higher 
purpose than just wandering randomly around the 
room. Let’s make a cricket-like behaviour, a bug 
that looks for a dark corner in which to hide. We 
describe the behaviour that makes our robot seek 
darkness and avoid light as photophobic which 
means ‘fear of light’. Fear is a living being’s emo- 
tion, but we can make our robot appear to fear light 
with this behaviour! Build the light sensor circuits in 
earlier instalments to use this code. To read the 
photocells we will use the Stamp II instruction 
rctime. Reading a photocell takes time, the darker it 
is, the longer it takes to read the cell. Because it 
takes so long to read a single photocell, we will 
want to break up the readings into different states, 
doing the math to determine whether or not the left 
or the right photocell sees brighter light also takes 
time. We don't want our robot to stop and think 
every time it looks at the light readings to the left 
and right, so again, these will be separate states. 
When we have made a decision, we want to turn 
in the direction of the darker reading. We should 
turn for a while, so we will be setting a duration for 
the turn as well as a direction. If we don't have a 
certain duration, our robot could easily jerk back- 
and-forth, which doesn't look like its being very 
decisive! This will be a more complex state 
machine than our previous ones because it has five 
states instead of two. Here is a list of actions that 
will need to be done: 


state 0 
Read light level on left photocell 
set state = 1 

state 1 


Read light level on right photocell 

Modify this value by 1.5 because this cell reads a 
little lower than the other one 

set state = 2 
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Figure 25. Proposed state machine for photophobic behaviour. 


State 2 
Add margin to left reading 
If left is brighter than the right 
set [Dir = turn right (tr) 


set IDur = 30 
set Istate = 4 (next state is decre- 
ment) 
Else 
Set lstate = 3 
State 3 


Add margin to right reading 
If right is brighter than the left 
set [Dir = turn left (tl) 


set [Dur = 30 
set Istate = 4 
Else 


Set lstate = 0 (do nothing, both sides 
are about the same) 
State 4 
Decrement |Dur, IDur = |Dur — 1 


If Dur = 0 
set lstate = O (start over from begin- 
ning, we are done) 
Else 
Do nothing, come back to state 4 
again for a decrement, we are still turn- 
ing 


Figure 25 shows the state machine we 
will be using for our photophobic behav- 
1OUI. 

This state machine was drawn only 
after all of the actions that were required 
had been written down and organized in 
a logical manner. Because we are chang- 
ing variables and passing data between 
these states, we really should include 
that in the transition function arguments 
(the captions on the arrows). Sometimes 
it is easier to create the state diagram 
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Figure 26. Wander/seek actions defined in terms of subsumptive programming. 


and build the functionality of each state 
from that graph. There is more than one 
way to build a behaviour, this is just one 
suggested design. 

Notice that the description of the 
states is pretty detailed. Your descriptions 
should be this detailed so that you don't 
forget anything that could be important. 
In State 1 a ‘fudge’ has been added to the 
reading. This is because no two photo- 
cells are the same, when these were 
measured, one read a little lower than the 
other, this modification evened out the 
photocells for comparison. This is some- 
thing for you to check with your photo- 
cells too. Of course, since our state 
machine is quite a bit more complex, you 
can expect the code to be more complex 
as well. It is, but if you write the steps 
that need to be taken very carefully, in a 
programming-like language (as seen 
above), you can practically write the soft- 
ware straight from your state description. 
This ‘almost’ programming language is 
called pseudo code, it helps you to orga- 
nize your thoughts logically. If you can't 
write it down, you can't program it! The 
actual Stamp II code for this behaviour is 
shown in Listing 13. 

There are a few subtle short cuts in 
this code. The tmp = pright >> 1 
statement divides pright by two and 
stores the result in tmp, then the next 
line adds tmp to pright. This multiplies 
pright by 1.5 to compensate for its 
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lower readings than the left photocell. 
The branch statement is a way to branch 
to a different section of code based on an 
index value, in our case that index value is 
our state. 

Add the variable and constant column 
on the left to the top of your program. 
Add the lightlook behaviour subroutine to 
the end of your program. Add this behav- 
iour to the main programming loop like 
this: 


‘set up for running 

wstate =0 ‘initial wander 
state 

lstate =0 
phobic state 


‘initial photo- 


main: 
gosub wander 
gosub lightlook 
gosub act 

goto main 


What do you think will happen? The wan- 
der behaviour will set the variable drive 
to some random direction, however, the 
lightlook behaviour, knowing nothing at 
all about wander will then set drive to 
some other direction perhaps, if it sees a 
darker corner to run to. Finally, act will 
use the drive value to determine which 
motors to drive in which direction. So, the 
lightlook behaviour will have a higher pri- 
ority than the wander behaviour because 
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Figure 27. Subsumption network diagram for a photophobic robot. 
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it gets the opportunity to set the drive variable after 
wander does. Are you starting to see the exciting 
possibilities with this type of robotic programming? 
Let's look at the subsumption network diagram in 
Figure 26 to see the behaviours we have just given 
our BoE-Bot. 

Here is a challenge for you! Turn our little pho- 
tophobic robot into a cricket that hides in the dark 
and chirps. You can start with this list of require- 
ments: 

- Both photosensors must read some low level of 
light (high reading = low light) 

- When the low light threshold has been reached, 
the robot must stop there 

- Use the last readings taken from lightlook, this 
means you won't need to take new readings 

- ‘The robot will only chirp when it is standing still 
in the dark 

- ‘This will be higher priority than the lightlook or 
wander behaviours 

- If either sensor's value goes above the threshold, 
then the robot will move again 


By using the last read light values that were taken 
by the lightlook behaviour we are violating the 
strict rule of independent modules. However, in the 
interest of saving the time that these readings 
would take, this is a small infraction. Besides 
which, this isn't a traffic law, and very little side- 
affect occurs from this minor violation. Feel free to 
add the rctime functionality if you wish. 

Now your task will be to create a detailed list of 
actions that must occur in each state of this finite 
state machine. Then draw a state diagram, decide 
where this behaviour belongs in your robot's sub- 
sumption network and finally write the behaviour 
code and insert the gosub for the behaviour into the 
main loop. Make sure you initialize your state 
machine in the Set up section before the main 
behaviour loop! 


Phase 4: 
the Avoid behaviour 


We have random movement and photophobic 
behaviours programmed into our robot now. How- 
ever, BoE-Bot does not have any way to avoid run- 
ning into things. A behaviour that will avoid walls 
and furniture will certainly extend the usefulness 
of our little robot! Build the IR proximity detectors 
(IRPD) from an earlier instalment. Let's think about 
what we need to do to avoid collisions with objects. 
An enhancement to this behaviour would be to 
have the robot turn 180 degrees when it sees an 
obstruction directly in front of it. How would you go 
about creating this behaviour? 


Get IRPD readings 
If first reading then 
save it 
Else 
If this reading = last reading then 
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Li t = l 3 branch lstate,[lread1,lread2,1lcomp1,1lcomp2 | 
IS ing lDur = 1Dur - 1 ‘state 4 decr duration 
drive = 1Dir ‘correct direction 
‘light looker vars and constants if 1Dur > 0 then 1Donel ‘still counting 
LLIGHT con 11 ‘left sensor eate Haoa er e 
RLIGHT con 4 ‘right sensor pence rales 
pleft var word ‘left value TET 
pright var word ‘right value ireadi: otatte 0 
lstate var byte ‘FSM state rctime LLIGHT,0,pleft ‘get left value 
1Dur var byte ‘how long to go ieee ef. ‘go next state 
TDi var word ‘where to go qa Gar 
LMARG con 15 ‘light margin 
lightlook: lread2: ‘state 1 
low LLIGHT ‘set up for sensors rctime RLIGHT,0,pright ‘get right value 
low RLIGHT ‘branch takes 200us tmp = pright >> 1 ‘compensation 
pright = pright + tmp 
lstate = 2 ‘go next state 
Heuuen 
lcomp1: ‘state 2 
tmp = pleft +LMARG ‘set threshhold 
if tmp > pright then 1Done2 ‘left not past 
‘threshhold 
lDir = tr oriee to lett 
lDur = 30 ‘for a while 
lstate = 4 ‘go decr state 
bercuBn 
1Done2: 
lstate = 3 ‘2nd compare 
ie Shelon gia 
Leomnpe2: ‘state 3 compare 


tmp = pright +LMARG ‘set threshhold 
if tmp > pleft then 1Done3’not past 


1Dir = tl ‘bright to right 
lDur = 30 ‘for a while 
lstate = 4 ‘go decr state 
return 
lDone3: 
lstate = 0 ‘none past 
return 
Choose direction and set drive This one isn't as complex as the lightlook simple that no state machine really needs 
Clear reading history behaviour; going around something is a to be built. One could say that this behav- 
Else simpler behaviour than actively seeking iour really does have two states, the first 
save this reading something (dark) is. Some things are so just takes an IRPD reading, the second 


- - avoid:'IRPD routine 
Listing l4 High IEN ‘enable 555 


i=0 
‘TIRPD vars and constants i= ileft +2 F iright ‘read IRPD 
ileft var in9 ‘IR LED outputs low IEN ‘disable 555 
iright var in0 ‘1=(see code) if ilast = I then ickit ‘two reads agree 
IEN con 5 ‘enable for 555 goto iDone ‘just first read 
ilace ss vat byte ‘hit counter ickit: ‘This line chooses new direction 


lookup 1,[(rr,tr,tl,drive),tmp 
drive = tmp 


i=0 ‘clear history 
iDone: 
ilast = i ‘new history 


return 
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takes another and sees if they agree. 
However, these two actions are so closely 
coupled that it would be difficult, and 
unnecessary to separate them out. 

Our code for avoid is shown in List- 
ing 14. 

Math in the Stamp II is evaluated from 
left to right, so you either must be careful 
of your order of operations or use explicit 
parentheses to force the correct order. 
The IR demodulators that we are using 
detect a signal by sending a ‘low’ or ‘0’ 
back on that I/O port line. Therefore, with 
our code above, a 3 means no detection, 
a 2 means detection on the right, a 1isa 
detection on the left and a 0 is detection 
on both lines. Our Jookup instruction 
includes the old drive value in its list, this 
is done so that we can change nothing if 
there is no detection, and not modify the 
drive value at all. The avoid module will 
continue to change our robot’s direction 
until there is no obstacle detected. ‘This 
will look like a smooth search until the 
path is clear! 

To add this behaviour, place the vari- 
ables and constants block near the top of 
your current program and put the avoid 
Subroutine in your behaviours code sec- 
tion. Since we want avoid to have higher 
priority than any other behaviour we have 
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done so far, place it in the main loop as 
shown below: 


‘set up for running 


wstate =0 ‘initial wander state 
lstate =0 ‘initial photophobic 
state 

ilast =0 ‘initial avoid history 
value 

main: 


gosub wander 
gosub lightlook 
gosub avoid 
gosub act 

goto main 


Figure 27 shows our subsumption net- 
work diagram with all of our behaviours 
included. 

Subsumption networks are quite useful 
to explain the potential activity of our 
robots to others. They can be used to pre- 
dict behaviour or to compare behaviours 
of other robots with our own. Reading 
these diagrams can be easier than study- 
ing other peoples’ programs! ‘This type of 
programming can be used in any appli- 
cation that needs good response to exter- 
nal stimuli that is not dependent on pre- 
cise time intervals. 


Here is another challenge for you and your BoE- 
Bot projects. Add a behaviour that will cause your 
robot to backup and turnaround when it bumps 
into an object. This will require you to build a 
bumper and connect it to an I/O port on the 
stamp II first. Then you will need to decide on a list 
of actions that need performed, break these actions 
into states and decide what you will need to 
remember. You will also need to decide what prior- 
ity a bumper reaction should have in your sub- 
sumption network. You now have a set of tools for 
programming these behaviours into your BoE-Bot, 
go have fun! 
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Internet 


http://www.parallaxinc.com — BASIC Stamp 
Manual Version |.9, BASIC Stamp DOS and 


Windows Editor, program examples. Interna- 
tional distribution sources. 

http://www.stampsinclass.com — BoE documen- 
tation, Robotics curriculum, BoE-Bot *.dxf and 
* dwg drawing formats, discussion group for 
educational uses of BASIC Stamp. 

chucks@turbonet.com — creator of the BoE-Bot 
and co-author of this series. Technical assis- 
tance. 

kgracey@parallaxinc.com — co-author of this 
article. Technical assistance and questions about 
the educational program. 


http://www. milinst.demon.co.uk — UK distribu- 
tor of Parallax BASIC Stamp. 


33 


